You can solve this in webpack by setting fs to empty:

node: {
  fs: "empty"
}

I know, I was doing this before PostCSS 6, but don't you think it's better to declare this in the project instead of everyone's webpack config ? Would save people's time in my opinion.

It's only easier if the whole dependency tree of your webpack bundle uses this field (and if they don't, you still have to define fs as empty). To be honest I don't like either solution, seems like it should be a case that webpack handles by default.

I don't understand why it is such a big deal to add this field in package.json, anyway I will do it in my webpack config.

So why not adding this field in all modules from npm?

To me it feels like a really bad way of fixing some behaviour. npm has hundreds of thousands of modules, why do we have to update them all when we could update webpack itself to handle the most common case?

Some modules have a hard requirement for fs, some have not. It may be dangerous to override fs for all dependencies. Having a browser field in package.json let you state explicitely that this module can run in a browser and that the following node modules can be omitted.

OK. Then I will reconsider this pull request on the condition that we add in a unit test for this behaviour; perhaps we might be able to swap out jison for some other parser in the future (jison being the source of the fs call).

I don't know what kind of unit test you expect here. It is not trivial to detect if one of the project dependencies uses fs, neither to detect if a bundler correctly uses the browser field.

I think having some kind of webpack bundle test would be sufficient, to make sure that the module compiled OK and that there were no errors thrown. We do this for cssnano: https://github.com/ben-eb/cssnano/blob/master/src/__tests__/webpack.js

This is a huge dependency for such a simple change. I don't think it's worth it.